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Remarks/Arguments 

Claims 1-42 are pending in the application. Claims 1, 21 and 42 are 
independent. 

Claims 1,21 and 42 are amended. No new matter has been added by way of 
these claim amendments. 

New independent claim 43 is added, directed to an embodiment wherein the 
access request is based on certain keywords included in the request content. 



Claim 1 as amended recites: a method for providing dynamic interaction between 
a pair of application programs by an interface module of a terminal, the pair of 
applications including a requestor application desiring access to a target 
application, the method comprising the steps of: 

registering access information of the target application, the access 
information including published access information made available in a data 
structure for retrieval by the interface module; 

receiving an access request by the interface module from the requestor 
application, the access request including content corresponding to the published 
access information of the target application; 

obtaining an interface component by using the request content to search 
the data structure, the interface component configured for enabling 
communication between the interface module and the target application in an 
access format expected by the target application; and 

employing the interface component by the interface module to satisfy the 
access request of the requestor application for interaction with the target 
application. 
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The Examiner has rejected claims 1-7, 12-14, 19-27, 32-34 and 39-42 under 35 
U.S.C. 102(e) as being anticipated by Slaughter, US patent no. 7,458,082. 
Applicant respectfully traverses the rejections. 

As described in the Background of the application as filed, the problem the 
subject invention addresses relates to communication between related 
applications. Specifically, if an application interface changes, it is also required 
to change many, or all, of the related or dependent applications to maintain 
compatibility and interoperability. 

The solution as disclosed provides an interface module that facilitates the 
communication between a requestor application and a target application. The 
target application registers access information, such as an application name and 
its corresponding parameters. The requestor application submits an access 
request for the target application, which is received by the interface module. The 
requestor application also provides content corresponding to the published 
access information of the target application. 

The interface module uses the received information (in a generic format such as 
XML, for example) to obtain an interface component, which is configured to 
enable communication between the interface module and an access format 
expected by the target application. The interface component is then used by the 
interface module to satisfy the access request. 

In the Advisory Action dated 09/24/2009, the Examiner pointed out, in the 
Continuation of Item 11, that the message layer 104 and the API layer 102 of 
Slaughter are corresponding features to the interface module and the interface 
component, respectively, of the present application. 

There are a number of elements of claim 1 that are not present in Slaughter. 
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Firstly , there is no teaching of the messaging layer 104 of Slaughter "receiving 
an access request from the client including content corresponding to published 
access information". Slaughter is silent regarding the form of the request from a 
client/ requestor, specifically that the access request includes content related to 
the published access information, for instance via certain keywords. In contrast, 
the present application provides an example of this feature, wherein for example, 
the access request is based on certain keywords included in the request content: 

Example: API lookup using keyword scoring algorithm, referring to Figure 3. 

1. Application A is a Calendar application 107 that registers its API 124 in the 
table 302 specifying API keywords 'CALENDAR', 'APPOINTMENT' and 
'MEETING'. 

2. Application B is a Holiday Viewer application 107 and registers its API 124 
specifying API keywords 'CALENDAR' and 'HOLIDAY'. 

3. Based on the above, an Application C is a Service Call Planner application 107 
executing a dynamic lookup using the API 124 lookup keywords 'CALENDAR' 
and 'APPOINTMENT'. Accordingly, the interaction module 312 returns the API 
Descriptor of application A from the table 302, as it scored more in keyword 
match. The Application C can validate the retrieved API Descriptor and, if 
satisfactory, could lookup the corresponding application 107 (or handler 122) 
identifier via the table 300 for the returned API instance. In this example, 
Application C would then access application A (e.g. best match) using the 
standard interaction protocol of the interaction module 312 as described above in 
reference to Figure 4. 

Secondly , Slaughter does not disclose "obtaining an interface component by 
using the request content to search the data structure ". 

Slaughter discloses at Col. 11 Lns. 9-13 that "The API layer 102 is concerned 
with the discovery of and the connecting of clients and services. The API layer 
102 provides send message and receive message capabilities. This messaging 
API may provide an interface for simple messages in a representative data or 
meta-data format, such as the extensible Mark-up Language (XML)." Yet 
further, Col. 11 Lns. 30-32 provide "In one embodiment, XML messages are 
generated by messaging layer 104 according to calls to the API layer 102." 
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However, there is no disclosure in Slaughter as to how an appropriate API is 
obtained, such as for example, by using the request content of the target/ 
service, as disclosed in the claim 1 feature of "obtaining an interface component 
by using the request content to search the data structure ". 

Therefore, for at least the reasons discussed above, Applicant submits claim 1 is 
patentable in view of Slaughter and, as such, requests that the rejection of claim 
1 be withdrawn. 

Independent claims 21 and 42 include similar limitations as claim 1, and 
therefore a corresponding argument applies. Accordingly, Applicant submits that 
the rejection to these claims be withdrawn for at least the same reasons 
discussed above with regard to the Slaughter reference. 

Since the remaining dependent claims depend from one of the above noted 
independent claims, Applicant submits that the rejection of these claims be 
withdrawn for at least the same reasons. 

For the foregoing reasons, the Applicant respectfully submits that the claimed 
invention is patentable over the prior art. Reconsideration and allowance are 
respectfully requested. 

Respectfully submitted, 

/Henry Ohab/ 
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